Some additions and changes have been made to the software in this development package. The following list describes these changes along with some information on using the Thread Manager.
1) The big changes:
--> The Thread Manager is now built into the System 7.5 reference release for both 680x0 and Power Macintosh platforms. The Thread Manager contains the Thread Mangager shared library which is what power applications call to use the Thread Manager. Using the native PPC Thread Manager does require compiling your code native for Power Macintosh machines. Read the READ ME for more information on how to compile your application using the new shared library. You'll find all you need in the folder named "Compiler Stuff". Also included is an updated version of the documentation that includes all information about the Power Thread Manager.
--> The 2.1 version of the Thread Manager has enhanced debugging support for new source level debuggers. The new Power Mac Debugger 2.0 & 68K Mac Debugger 2.0 both support the new Thread Manager debugging interfaces and allow you to debug your threaded applications at the source level. System 7.5 Update 1.0 or System 7.5.1 (has 7.5 Update 1.0 built in) will be required to debug applications with Mac Debugger 2.0. Please read the debugger documentation for information on working around this restriction.
2) The following bug fixes have been made to the 2.1 version of the Thread Manager which is included here as an system extension for non-7.5 systems and is built into System 7.5 Update 1.0 and System 7.5.1.
--> v2.1 Fixed a bug where the preemption timer would fail to run after the first preemptive 68K threaded application was launched.
--> v2.1 Fixed a problem in the previous QuickDraw fix for the stNoStack routine. This bug was fixed in the Thread Manager which shipped inside system 7.5.
--> v2.1 Fixed a problem with the debugger call backs - there are now two sets of debugger callbacks, one set each for 68K and PPC routines. When a 68K application registers for the debugger callbacks, only the 68K routine proc pointers get set and run. It is no longer possible to mix and match debugger callbacks between processor worlds. This change fixes problems with the VoodooMonkey debugger setting 68K callbacks for PPC applications and crashing a horrible death when the 68K code gets called directly from the PPC Thread Manager. This bug was fixed in the Thread Manager which shipped inside system 7.5.
3) The latest version of Mode32 is now compatible with system 7.5 and the Thread Manger.
4) The source level debugger VoodooMonkey has been removed from the Thread Manager development package. This was done to reduce the size of this package so it will continue to fit on a single floppy disk. The latest version of VoodooMonkey suports both 68K and PPC source level debugging and has grown in size such that it, with all of the Thread Manager files, will no longer fit on a single floppy disk. VoodooMonkey may be found on various FTP sites and developer CDs.
5) New examples. The same old 680x0 examples are included in this package as well as some simple PowerPC Thread Manager examples.
6) There is a new version of the SortPicts sample application with source code. This version fixes a bunch of problems with the old SortPicts sample app and is built around a really kool skeleton application which supports tons of new 7.5 features.
7) There is a bug in the Traffic Simulation sample application with regard to custom context switchers. The custom context switchers in the application assume that register A5 points to the application globals, when in fact, it is not guaranteed to. The author of this application has been publicly chastised for not following the Thread Manager documentation about custom context switchers and A5. The fix to the code is left as an exercise for the reader.
8) General Thread Manager information:
-- The caller of DisposeThread can decide if the thread is reclaimed in the thread pool. If the thread calling DisposeThread is a preemptive thread, the disposed of thread is ALWAYS reclaimed in the thread pool to prevent Memory Manager calls from being called at preemptive thread time. When a thread RTS'es, it will not be reclaimed into the thread pool unless it is a preemptive thread (for the above reason).
-- Thread termination routines can rely on register A5 being valid when they are called. Thread termination routines can make all the thread calls a thread can make. The thread result is set before the thread termination routine is run.
-- For those of you who use SIOW applications, make sure you call MaxApplZone WAY early in your main routine since the SIOW code does not do this for you. Forgetting to do so will result in a major protocol error (crash). Also, the latest SIOW library supports native PPC applications.
-- A ThreadTaskRef is unique for each application launched and does not change during application execution.
-- Allocation from a thread pool works as 'best fit' for the new thread stack size unless the new thread creation option, kExactMatchThread, is used.
If you have any bug reports or comments, please don’t hesitate to link or write. You can contact us through the following:
Alink: DEVSUPPORT (provided you have Apple developer support access)
or
Eric Anderson: ALink: Eric3, AOL: ERICTHREE
...or place your comments in the Developer Talk bulletin boards on AppleLink, the internet, Compuserve, AOL, or some other public discussion area.
